• 菜雞行為：把職場當成已經出好題目的考場
• STAR 階段：S (Situation)
• 本篇定位：先把我如何將模糊工作誤認成已定義考題的情境說清楚。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

這是三日故事的第一篇，只談 Situation：當時發生了什麼、我怎麼理解，以及問題如何露出來。真正的任務、限制與驗收條件，留到 Day 02；採取的做法與得到的結果，留到 Day 03。

這也是整個系列的起點。我想整理的「學生味」不是學生身分，更不是拿年紀或年資替人貼標籤，而是一種我確實帶進工作的習慣：把職場當成一張已經出好題目、只等我寫出標準答案的考卷。

我很會回答，卻沒有先確認該回答什麼

在學校解題時，題目通常已替我完成大量前置工作。誰要解、輸入是什麼、輸出長什麼樣子、可以使用多少時間與記憶體，多半寫在題幹裡。即使題目有陷阱，至少「要解哪一題」通常不是考生的責任。

我很習慣這套節奏：讀題、辨識題型、搜尋記憶裡的解法，然後開始寫。這不是毫無用處的壞習慣。面對邊界清楚的程式題、可重現的錯誤，或已經定義好的小修改，它讓我很快進入狀況。問題出在，我把同一套節奏搬到尚未定義好的工作上，還以為自己只是「反應快」。

只要聽到一句功能要求，我腦中就會自動補成技術題。有人說「增加搜尋功能」，我已經在想資料表欄位、全文索引、分頁、套件和 API。手還沒碰到鍵盤，心裡的實作可能已經跑完半圈。

但我其實還不知道：誰要搜尋？在什麼情況下搜尋？現在卡住的事情是什麼？找到資料之後，要做哪個判斷或動作？

很會回答問題，不代表我已經確認現在該回答哪個問題。

粉鳥工單服務：一句「加搜尋」長出一串答案

以下是「粉鳥工單服務」的虛構案例，用來呈現這種工作習慣，不對應任何真實公司、人物或專案。

需求原句只有：「工單要能搜尋。」

菜雞版的我立刻把它翻成「替工單列表加關鍵字搜尋」。接著自然會想到搜尋哪些欄位、要不要模糊比對、索引怎麼建、資料量大時如何分頁。每個問題都很像工程問題，而且確實可能需要處理。於是我得到一種危險的安心感：我已經在工作了，而且想得很完整。

真正讓我不安的，不是這些技術問題答不出來，而是它們全部答完之後，功能仍可能沒有處理原本的困難。使用者也許不是要找「包含某個字」的工單，而是要找出已失敗、尚未結案，而且需要追蹤的項目。也可能只有特定角色能看某些工單，或者現有資料根本沒有支援判斷的欄位。

這些不是後端技術的附加題，而是決定題目本身的條件。可是當時的我把它們放在「之後再問」的位置，先把熟悉的部分當成主線。

[一句要求] --> [直接選方案] --> [開始實作]
     |
     +--> [使用者、情境、目的仍未知]

這張圖沒有列出完整的澄清流程，只標出本篇的問題：我從一句要求直接跳進方案時，被留在旁邊的不是小細節，而是使用者、情境與目的。這三項若仍未知，後面的技術選擇再漂亮，也只能證明我很會解自己出的題目。

當時的我為什麼覺得合理

太快進入解法，不一定來自自大，也可能來自很普通的工作壓力。收到要求後，立刻提出技術方案，看起來具體、有進度，也比承認「我還不知道真正要解什麼」更像一位有產出的工程師。

而且，熟悉的技術細節會給我控制感。資料表、索引與套件都能查文件、做比較、寫程式；使用者真正卡在哪裡，卻可能需要來回確認，答案也未必整齊。前者像考題，後者像一團還沒整理好的現實。我很自然地先抓住前者。

這就是我想說的學生味：不是只會課本，也不是沒有實作能力，而是預設別人已經把問題定義完整。我以為自己的責任從「解題」開始，沒有發現真實工程工作常常更早就開始了。

我真正漏掉的是題目邊界

回頭看，我漏掉的並不是一句神奇提問，而是三種仍未確認的資訊：誰遇到問題、問題在什麼情境發生，以及完成後要支援哪個行動。

在「搜尋工單」的例子裡，搜尋只是提出者目前想到的方案。它可能是對的，也可能只解決表面。只要題目邊界還沒確認，我就無法判斷搜尋欄位、權限、效能與畫面是不是必要，更無法說明什麼情況算完成。

本篇先停在這裡。我還不急著把需求澄清整理成一套完整方法，也不宣稱停下來就一定比較快。此刻能確認的只有：我不能再把一句要求直接當成已定義好的任務。

粉鳥工程筆記：先看見自己正在搶答

我目前替自己留下三個觀察點：

• 聽到功能名稱後，我是否立刻開始選資料結構、套件或畫面？
• 我能否說出使用者、發生情境與想完成的行動？
• 如果拿掉目前方案，我還說得清楚原本的問題嗎？

這不是完整的需求分析模型，只是一個煞車燈。小而明確、風險很低的修改，口頭確認可能就足夠；若填表的成本比誤解與重做還高，也不必為了表現專業而增加流程。

今天可以帶走的練習

挑一個最近收到的功能要求，花十五至四十五分鐘，只做以下四件事：

1. 原樣記下要求，不先把它改寫成技術方案。
2. 記錄提出者的職責，不放姓名或可辨識資訊。
3. 寫下目前已知的使用情境；不知道就明確標示未知。
4. 寫下自己第一個想到的解法，但先不要設計或實作。

明確產出是一則短紀錄，至少包含「要求原句、提出角色、使用情境、第一個解法」。以粉鳥工單服務為例，可以寫成：

• 要求原句：工單要能搜尋。
• 提出角色：工單處理者。
• 使用情境：尚未確認。
• 第一個解法：替列表加入關鍵字搜尋。

驗收方式不是把四格全部填滿，而是能清楚區分「已知資訊」與「我先想到的方案」，且尚未開始設計。若紀錄裡出現公司機密、個資、內部網址或可辨識人物，就不算通過；先刪除或抽象化。

很小、可立即復原，而且雙方對情境已有共同理解的修改，不必完整填表，一句文字確認也可以。當要求跨角色、影響資料或權限、驗收容易各說各話，或重做成本較高時，再使用《需求澄清卡》。工具的價值是降低誤解與重做，不是證明我有照流程工作。

# 需求澄清卡

## 用途

把一句功能要求往回追到使用者、情境、問題、限制與驗收。

## 使用時機

- 需求、設計、審查、交付或回顧需要留下可被他人理解的證據時。

## 不適用情況

- 問題極小且口頭確認已足夠。
- 填表成本高於實際風險。
- 只是為了證明有流程，而沒有實際決策用途。

## 範本

| 需求原句 | 使用者 | 發生情境 | 真正問題 | 目前方案 | 限制 | 待確認事項 | 驗收方式 |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |

## 使用提醒

- 只填寫會影響判斷、交付或驗收的資訊。
- 不放入密碼、Token、個資、公司機密或可辨識同事的內容。
- 不使用模糊百分比或「應該可以」取代證據。
- 表格不是目的；能降低誤解、風險或交接成本才有價值。

下一篇

下一步 (STAR 的 Task) 不是「把搜尋功能做完」，而是先回答：一句功能要求要補上哪些資訊，才能成為可分工、可限制、也可驗收的工程問題？